git and GitHub

A practical introduction

Daniel Thédié

18/02/2026

Expectations of conduct


  • Chatham House rule applies
  • Feel free to ask questions at anytime
  • Everyone’s voice matters
  • Be open to other points of view

What makes you
want to use GitHub?

What makes you
not
want to use GitHub?

Basics of git and GitHub

What is a git repository?

  • A (local) folder
  • A .git folder that contains all the file history

It can be:

  • Moved
  • Renamed
  • Uploaded, downloaded

…still a git repository

How are changes recorded

  • A commit records a snapshot of the project
  • It is identified by a unique “hash”, e.g. 87c0c975daf0643d59a01222b312662d347e0bfa
  • Shown on GitHub as the first 7 characters for readability: 87c0c97

Is git overly complicated?

Can we not make a google docs for code?

  • Real-time updates
  • Collaboration + sharing
  • Complete file history

What git adds…


The process makes the user decide…

  • What they share (which files)
  • When they share (working on files locally and pushing them when ready)
  • Why they share (for other people to use the code, to collaborate on code…)

How to collaborate with git(hub)

Pull - Modify - Stage - Commit - Push

From theory to practice

  • Go to github.com
  • Click on “New”
  • Enter a name and description
  • Make repository public or private
  • Tick “Add a README file”

  • Click on “< > Code”
  • Copy the https link to the repository

  • In RStudio, create a new project
  • Select:
    • Version control
    • Git
  • Enter repository details
  • Identify to Github
  • Add some code files to the repository
  • They will be shown in the RStudio git tab

  • Stage the newly added files

  • Commit (with a message)

  • Push

    • Committed files are now on Github

.gitignore is used to specify files that should not be tracked

  • Open the .gitignore file
  • Add *.Rproj on a new line and save file
    • The .Rproj file has disappeared from the git tab
  • Commit .gitignore
  • Push

The Readme file

A practical overview of the repository, in markdown format

  • What can be found in here?
  • What’s the purpose of the code (+ inputs/outputs)
  • How to use the code
  • Who are the authors (with contact info)

Readme example

github.com/BioRDM/Network-Analysis

git branches

Why use branches

Why use branches

Why use branches

Why use branches

Creating a branch

  • Create a new branch called “dev” in your repository

  • Make some changes to a file (on the dev branch)

  • Stage, commit, push

  • Switch between branches (= “checkout”)

    • The modified file changes depending on the branch

Good coding practices

Code modularity

library(readxl)
library(ggplot2)

sessions_file <- "example_sessions.csv"
min_sleep_period <- 2  # hours

file_ext <- tolower(file_ext(sessions_file))
if (file_ext == "csv") {
  sessions <- read.csv(sessions_file)
} else if (file_ext %in% c("xls", "xlsx")) {
  sessions <- read_excel(sessions_file) |>
    as.data.frame()
}

sessions <- sessions[sessions['sleep_period'] >= min_sleep_period * 60 * 60, ]

p <- ggplot(sessions, aes(x = .data$night, y = .data$variable, color = .data$color_group)) +
  geom_point(size = 5) +
  color_scale +
  labs(x = NULL, y = variable, color = NULL) +
  theme_minimal(base_size = 16) +
  theme(axis.text.x = element_text(angle = 45, hjust = 1))

print(p)

Code modularity

sessions_file <- "example_sessions.csv"
min_sleep_period <- 2  # hours

sessions <- load_sessions(sessions_file)

sessions <- set_min_sleep(sessions, min_sleep_period)

print_timeseries_plot(sessions)


  • Makes code more human-readable
    • Creates different “levels of reading”
  • Facilitates reuse in different scripts
  • Facilitates collaborative work

1. Create functions

  • A “processing unit” with clear inputs and outputs
  • Can be described simply with a verb + a noun
    • “load_data”, “set_ema_period”
  • In general shorter is better

Syntax for R functions:

set_min_sleep <- function(sessions, min_sleep) {
  sessions <- sessions[sessions['sleep_period'] >= min_sleep * 60 * 60, ]
  return(sessions)
}

2. Split code between different files


source("filtering.R")
  • One file per “topic”
  • If a file gets very long, consider splitting it
  • Easily see what part of the code a commit has affected

Make your own code more modular

  • Checkout dev branch
  • Create functions
  • Organise them in different files

Function template:

set_min_sleep <- function(sessions, min_sleep) {
  sessions <- sessions[sessions['sleep_period'] >= min_sleep * 60 * 60, ]
  return(sessions)
}

…commit and push your changes to github

GitHub functionalities

Make your first pull request

On github, create a pull request to merge dev into main.

Merge the pull request

When merges are more complicated

When merges are more complicated

Issues

  • Shared to-do list
  • Discuss about bugs or new developments
  • Useful info for other users/developers
  • Foster a culture of openness!

Github doesn’t own git!

…but Microsoft owns GitHub…

…and the Uni’s own GitLab instance! git.ecdf.ed.ac.uk

Thank you!

Find the presentation and help sheets on GitHub:

github.com/BioRDM/practical_git_workshop